FYI @kevinjqliu @CTTY I'm hoping this is a mid-term fix for the PyPI trusted publishing. We're unblocked for 0.10.0-rc1 but for later releases, I'm hoping this simplifies things.

If not, I think we need an update to the release guide to specifically call out the need for manual workflow dispatch to complete the PyPI RC publish.

Thanks for working on this!

What do you think about making release_python.yml standalone instead? It doesnt look like theres a need for release_python.yml to depend on publish.yml.

As long as both are using the same trigger, both can run independently and we'll produce the same artifacts.

I believe PyPi is already configured with release_python.yml, so no need to change that either (I'll double check this)

EDIT: yep, pypi is configured with release_python.yml already

Repository: apache/iceberg-rust
Workflow: release_python.yml
Environment name: pypi

I noticed we could do this too.

My thinking is that we wouldn't want to release the Python bindings if the crate itself couldn't be released (although perhaps we think the same of the Python bindings too). I'm a little wary since we do not do a publish to crates.io until after RC, so if something goes wrong there, we've already published the Python bindings release.

I don't have a strong preference, let me know what you think!

I'm a little wary since we do not do a publish to crates.io until after RC, so if something goes wrong there, we've already published the Python bindings release.

ah, i think that's exactly why we (i?) added the dependency link originally 😄

i prefer to keep them separate and just manually fix/upload if publish.yml fails (thats what we did last time). It would be good to verify that publish.yml can run properly during release. Maybe we can add publishing to crates.io as part of the RC process, the crates can be published as pre-release artifacts.

I'm a little wary since we do not do a publish to crates.io until after RC, so if something goes wrong there, we've already published the Python bindings release.

ah, i think that's exactly why we (i?) added the dependency link originally 😄

i prefer to keep them separate and just manually fix/upload if publish.yml fails (thats what we did last time). It would be good to verify that publish.yml can run properly during release. Maybe we can add publishing to crates.io as part of the RC process, the crates can be published as pre-release artifacts.

OK, sounds good. I'll open an issue on publishing pre-release artifacts as I believe that is supported by crates.io (the rc crate wouldn't be picked up unless explicitly asked for) and rework this PR to be independent of publish.yml.

Applied the updates. @kevinjqliu I have disabled the skip existing flag as I'd like to flag when the RC will not be replaced. I'm hoping rebuilding the RC as rc n+1 is cheap enough before the vote. Let me know what you think.